Security-JAWS第6回レポート #secjaws #secjaws06

阿部洸樹

2017.08.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

8月24日にSecurity-JAWS 第6回が開催されました。
参加レポートをご紹介します。

Session1:クラスメソッド株式会社佐々木大輔「ざっくりわかるAmazon Macie」

内容

佐々木のブログをご覧ください。

Session2:NRIセキュアテクノロジーズ株式会社大島修さん「AWSで実践するリスト型アカウントハッキング対策」

内容

アカウントハッキングの被害事例をみると、攻撃者は金銭目的であることが多い

種類

ブルートフォース攻撃
リバース型ブルートフォース攻撃
ジョーアカウント攻撃
リスト型攻撃
- 流出したID,パスワードを使う。IDやパスワードの使い回しをしていると危険
類推攻撃
- 個人の社会背景を使う
なりすまし

リスト型攻撃

リスト型攻撃の元になるID情報漏洩は常時どこかで発生
リスト型アカウントハッキングの典型的な攻撃シナリオ
- リスト試行
- 不正発覚防止
  - 連絡先の変更などにより、不正発覚を防止される
- 不正取引実行
- 証拠隠滅

アカウントハッキングは多層で防御

ブルートフォース攻撃：WAF、不正検知ツール
リバース型ブルートフォース攻撃：WAF、不正検知ツール
ジョーアカウント攻撃：WAF、不正検知ツール
リスト型攻撃：WAF、不正検知ツール
類推攻撃：不正検知ツール
なりすまし：不正検知ツール

AWS WAFでの防御

レートミリット設定
- 5分あたり2000アクセスが設定上の最小値
AWS WAF + Lambdaによる高頻度アクセスIPのブロック
- CloudFrontやELBログをLambdaに食わせて、WAFのブラックリストに追加
- AWSのGithubにLambdaのコードがあるので参考にできる

アクセス頻度を基準とした防御の限界

攻撃者は閾値をにかからない頻度でアクセスしてくる。閾値を探ってくる。
ボットネットを活用して、分散IPで攻撃してくると対応しにくい

不正検知ツールによる防御

複合コンテキストによるリスク分析
- 端末属性、ネットワーク属性、ページ遷移属性、地理属性、利用時間特性、サービス利用属性など
不正検知ツールによる防御
- NRIセキュアテクノロジーズでは、Uni-ID Identity Fraud Detectionを扱っている

まとめ

AWS WAFのレートリミットはすぐに導入すると良い
金品やポイント扱ってる場合、コンテキスト分析によるリスク検知の導入を検討
多要素認証は協力だが、ユーザービリティを落とさないように高リスク時にのみ有効化

Session3:F5ネットワークスジャパン株式会社牧田延大さん「BIG-IPをVPCエンドポイント的に使ってみた」

スライド

内容

セキュアなS3アクセス

VPC PrivateサブネットからのS3アクセスをセキュアに行う方法を考えて見た
- 1.NAT、IGWを噛ませてインターネットに抜ける
- 2.VPCエンドポイント
- 3.BIG-IP使って何かできそう
  - NATインスタンスの代わり
  - HTTP→HTTPS変換できる
  - IAMでのアクセス制御も可能

BIG-IPを使ったバリエーション

BIG-IPをS3アクセスのプロキシとして配置
- スキーム変更：HTTP（Private）→ HTTPS（Public）
- S3エンドポイントのヘルスチェック
- アクセス先URL書き換え（ホスト+パス）とトラフィック転送
  - iRulesを利用
- HTTPレスポンスからセンシティブな情報をサニタイズ
- IAMユーザによるpre-signed URL発行と代理S3アクセス
  - iRules LXを利用
iRules LX
- iRulesのHTTPリクエストハンドラで呼び出し
- IAMユーザーを使ってpre-signed URLを発行
  - nodejsを利用

通信フロー

EC2がHTTPアクセス
BIG-IPが受け取ると、IAMユーザーでpre-signed URLを発行する
BIG-IPが URLを上記URLを受け取る
HTTPをHTTPSに変換
HTTPSで期限付きURLでアクセスする

さらにBIG-IPでできること

コンテンツキャッシュ
インターネット側TCPコネクション多重化
WAF

デモ

Amazon LinuxからBIG-IPを経由して、curlでS3にアクセス
- 通常時：4〜5 MB/s
- キャッシュ有効化時：30MB/s

まとめ

BIG-IPはNATインスタンス兼、VPCエンドポイント的兼、CloudFrontとして使える
アップデート
- サービスディスカバリエンハンス
  - Auto Scalingするインスタンスの保護では、ELBが必要だが不要になった

CFTはこちらから。#secjaws #secjaws06 https://t.co/H5p0X0xBgC

— Nobuhiro Makita (@nobuhiromakita) 2017年8月24日

Session4:アマゾンウェブサービスジャパン株式会社酒徳知明さん「DevSecOps in AWS Multi-Account」

スライド

DevSecOps in Multi Account from Tomoaki Sakatoku

内容

マルチアカウントにする主な理由

ガバナンス
- セキュリティ及びガバナンス上の理由から、開発/テスト/本番で分けたい
課金
組織
- 業務ユニットに移譲したい
運用
- 構成変更時の影響を小さくしたい
とりあえずAWSアカウントを分けているが、継続的に管理できているケースは少ない

マルチアカウントの前に、IAMの機能について抑えておく必要がある

IAMのロールの機能を使って、セキュリティ負荷を小さくできる。
- IAMユーザーはあまり作りすぎない方がいい
- 10アカウントに10のユーザーを作ることは避ける
- 複数のアクセスキー、シークレットキーがあるとローテーションが難しい
IAMロール利用の例
- アカウントA
  - アカウントBに対する操作を行う場合、アカウントBにロールをかりに行くことで、一時的なクレデンシャル（テンポラリなキー）を発行される。
- アカウントB
  - アカウントBでクレデンシャルを作る必要はなくなる

Overview of BaseLine

管理用のアカウントとターゲットアカウントがある
ターゲットアカウント
- IAM Role（Assume Role）、CloudTrail、Configなどを設定しておく
- 上記をCloudFormationで展開する
管理用アカウント
- ターゲットアカウントでCloudTrailがOFFになった時に、SNSで管理用アカウントのAPI Gatewayに通知

CloudFormationのターゲットアカウントへの配布

Step Functionでやっていたが、いきなり使うのは難しかった。今はCloudFormationのStack Setを使うと良い
Stack Setsを使うことで、1つのテンプレートを複数のアカウントに配布できる
- CloudTrailを有効化するテンプレートなど、選べる。デプロイするリージョンの選択、アカウントIDの指定、オーガナイゼーションの指定が可能
- 管理用アカウントからターゲットアカウントへのCloudFormationの配布が非常に簡単になった

QA

Q. Stack Setでターゲットアカウントに配布するにはどうするのか
- A. ターゲットアカウントにIAMロールを作成しておく。手動で作成するのは面倒だが、CloudWatch Eventとオーガナイゼーションを使えば自動化できるはず。
Q. 特定のターゲットアカウントだけ異なる設定にしたいケースではどのように対応するのか
- A. Update Stackすれば同じ設定になる。今の時点では、オーガナイゼーションで分けて対応する形が良さそう。

Session5:株式会社ラック関宏介さん「AWS環境におけるフォレンジック」

内容

AWSインシデント事例1

発覚経緯：数10TBの通信が発生し、請求された料金をみて気がづいた
侵入被害：DDoS Bot、Webシェル、RAT、ハックツール
侵入原因：Tomcatの管理画面が公開されており、パスワードの推測が容易な状態

AWSインシデント事例2

発覚経緯：AmazonのAbuseからDDoSの攻撃になっていると指摘
侵入被害：DDoS Bot
侵入原因：古いバージョンのソフト、FWでポートが空いていた、デフォルトパスワード、ソースからインストールしており管理者権限で動いていた
- 社内の古いシステム検証用だった

AWSインシデント事例3

発覚経緯：サービスが原因不明の停止、負荷増大
侵入被害：Bitcoin Miner
侵入原因：古いバージョンのソフトウェア

AWSのインシデント傾向

SSHの不正ログインは少ない
- AWSのデフォルト設定がセキュア
検証用のサーバの被害が多い
- 気軽に立ち上げやすい
意図しない公開ポートからの被害
- オンプレに比べてFWによる制御がされにくい

フォレンジックとは

和訳すると、法科学、科学捜査
フォレンジック技術を使う利点
- 削除済みエリアから痕跡が見るかる可能性
- Rootkitの影響を受けずにマルウェアを検知
- OS上からのは見えない情報が調査可能
- メモリも取得できれば当時の状況を再現可能

フォレンジックの限界

削除済みエリアは使用されるたび上書きされる
- ローテションや攻撃者により削除されたログ
ユーザー操作の全てが追跡できるわけでは無い
- 更新時刻は最終更新時刻
- ディスクやメモちに残っていない痕跡は追えない
復旧の最善策はOSの再インストール

復旧時の注意事項

バックアップから戻す際に、Webシェルやバックドアとして動くコードを戻してしまう可能性がある
- クローズドなステージング環境から戻す形をおすすめ
- Web Sellの特定は困難。難読化されてしまうことがある。

ディスクのフォレンジックのためには

オンプレミスでは、ハードディスクのイメージコピーを取得
- AWSでは、フォレンジック用のハードウェアができない
  - ソフトウェアによるイメージコピー
AWSでのフォレンジック手法
- インシデントを検知したらスナップショットをとる
- スナップショットからボリュームを作成
  - AZを調査インスタンスに合わせるように注意
- 作成したボリュームを調査用インスタンスにアタッチ
- イメージコピー（ddなど）
  - S3経由などで手元にダウンロード
SSHを使ったLiveイメージング
- PermitRootLogin no、かつsudoできる場合
  - ssh -C 一般ユーザー@対象ホスト "sudo dd bs=512" conv=noerror,sysnc if=/dev/xvda > xvda-img.dd
  - 圧縮転送が効くため、CPU負荷はかかるが転送効率は良い